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Q can be the process of taking a network device (such as a router, gateway, gatekeeper, etc.) and exchanging encrypted information 

with die clearinghouse server, so that later communications with that device can be secured. The enrollment is done with levels of 
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SYSTEM AND METHOD FOR THE SECURE ENROLLMENT OF 
DEVICES WITH A CLEARINGHOUSE SERVER FOR INTERNET 
TELEPHONY AND MULTIMEDIA COMMUNICATIONS 

Priority and Related Applications 

The present application claims priority to provisional patent application 
entitled, "Automated Support of Internet Telephony Clearinghouse Services," filed 
on December 22, 1999 and assigned U.S. Application Serial Number 60/171,375. 

10 The present application is also related to the following pending applications: U.S. 
Provisional Patent Application Serial Number 60/231,642, entitled, "Clearinghouse 
Server for Internet Telephony and Multimedia Communications," filed on 
September 11, 2000, assigned to the assignee of the present application and hereby 
fully incorporated herein by reference; U.S. Application Serial Number, 

15 , entitled, "Call Detail Record Method and System for Internet 

Telephony Clearinghouse System," filed on December 22, 2000; U.S. Application 

Serial Number, , entitled, "User Interface for Internet Telephony 

Clearinghouse System," filed on December 22, 2000; and U.S. Application Serial 
Number, ' , entitled, "Rate Provisioning Method and System for 

20 Internet Telephony Clearinghouse System," filed on December 22, 2000. 

TECHNICAL FIELD 

The present invention is generally directed to telephony and 
multimedia communications carried by a distributed computer network, such as the 
25 global Internet. More specifically, the present invention relates to the secure 
enrollment of devices with a clearinghouse server so that communication can be 
routed between an originating device and a terminating device via the Internet. 

BACKGROUND OF THE INVENTION 

30 Telecommunications networks are experiencing a drastic 

technology shift-from a circuit-switched architecture (such as the current voice 
phone network) to a packet-switched architecture (such as the global Internet). 
Worldwide, the capacity of deployed packet-switched networks is doubling every 
year while circuit-switched capacity is only increasing at an annual rate of around 

35 6%. In many developed regions, packet-switched capacity already exceeds circuit- 
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switched capacity. Recognizing this trend, telecommunications providers have 
begun to optimize their netvorks for the technology that is expected to dominate 
future growth: packet-switching. As they deploy packet-switched technology, 
these providers must still support traditional circuit-switched applications such as 

5 voice — and— facsimile. Instead of operating parallel _netwqrk Jnfrastructures, 

however, clearinghouse service providers seek to support those applications over a 
packet-switched network. This approach offers several advantages: greater 
efficiency through the use of a single, common," network infi^tfucture; lower cost 
through a reliance on packet-switching equipmentrandbetter support of innovative 
1 0 new services through an open architecture. 

As circuit-switched applications move to a packet-switched 
network, service providers need a way to identify systems on the packet-switched 
network that are associated with addresses (typically telephone numbers) common 
to the circuit-switched world. Providers must also have a means to authorize 
15 communications, and to ensure that unauthorized communications do not consume 
bandwidth. For example, the provisioning of a physical, circuit-switched, 
- connection "between" two providers typically serves as authorization for the 
providers to share traffic. In a packet-switched environment, however, 
communicating parties need not share a physical connection and some other means 

„20 oflauthorizing-trafBc-is-requiredT— Finally, providers must have a reliable way to 

collect information from packet-switched devices to account for customer usage 
(e.g., for billing). 

There remains a need in the art for a convenient, centralized 
application to provide authorization, or enrollment, for circuit-switched 
25 applications in a packet-switched network environment. Enrollment is the process 
of taking a device and exchanging sufficient cryptographic information with the 
clearinghouse server so that later communications with that device can be secured. 

The conventional art does not provide an effective, secure way to 
enroll a device with a clearinghouse server. In particular, the identity of the 
30 clearinghouse server is verified by a telephone call. This verification has many 
drawbacks. Telephone calls are not automated, and require contact with people. 
As people have certain work hours, and cannot be relied upon to always be 
available, the telephone call verification is impractical, and time consuming. In 
addition, as packet-switched architecture becomes more and more popular, this 
35 problem will become more pronounced. 
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The present invention provides for the secure enrollment of a device 
for operation with a clearinghouse server, also described as a clearinghouse 
enrollment server, so that telephony and multimedia communications can be routed 
between an originating device and a terminating device via the Internet. The 
5 enrollment process is typically completed by a network device (such as a router, 
gateway, gatekeeper, etc.) and the clearinghouse server. This source device and 
the clearinghouse server can exchange encrypted information, so that later 
communications with that device can be secured. Once this verification process is 
finished, the device can have a public key certificate that is valid for a certain 
10 length of time (such as one year). Once this length of time has passed, however, 
the certificate can expire and the device must re-enroll. The enrollment process 
can also provide the device with a certificate authority's (CA) public key 
certificate. The device can use the CA's certificate to authenticate subsequent 
communications from other clearinghouse servers. 
15 To enroll, the device can tell the clearinghouse server its public key. 

Then the device can prove that it possesses the private key that corresponds to the 
public key. This can be done by taking information provided by the clearinghouse 
enrollment server, and having "the device encrypt it with the private key. The 
device can then send this information to the clearinghouse enrollment server. If 

20 the„dearinghouse enrollment server can then decrypt the information, the 

clearinghouse enrollment server can verify that the device possesses the private 
key. 

When the device tells the clearinghouse enrollment server its public 
key, a security issue arises. If an illegitimate user successfully intercepts, redirects, 

25 or captures the public key when it is sent to the clearinghouse enrollment server, 
the illegitimate user could take the place of the legitimate clearinghouse server. 
The illegitimate user could then be able to decrypt the encrypted message that the 
device sends, and would seem to be a legitimate clearinghouse enrollment server. 
Thus, the identity of the clearinghouse enrollment server must be verified. 

30 Rather than using the conventional telephone call to verify the 

clearinghouse enrollment server's identity, the present invention can rely on the 
Web infrastructure to securely identify the clearinghouse enrollment server. The 
present invention does this by having the device pre-configured with a third party 
CA certificate. The clearinghouse enrollment server obtains a public key 

35 certificate under the authority of this CA certificate, and it provides that certificate, 
along with proof of possession of the corresponding private key, in the initial 
communications with the device. 
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In view of the foregoing, it will be appreciated that the present 
invention provides a method for secure enrollment of a device with services of a 
clearinghouse enrollment server to supporting communications carried by an 
Internet telephony system. A device can initiate a request to enroll for the services 
5 of the clearinghouse enrollment serverrln-tum, the identity of the clearinghouse 
enrollment server is verified a communication exchange between the device and 
, ... _thejclearing house^enrol lment server. This exchange is supported by use of a . 

--^securityJnfiastmcture public key 

infrastructure. In response to verifying the identity of the clearinghouse enrollment 
10 server, enrollment of the device is completed at the clearinghouse enrollment 
server to all the device to access the communication services of the Internet 
telephony network. 

More specifically, the present invention provides a for secure 
enrollment of a device with services of a clearinghouse server for an Internet 

15 telephony system._In.response to obtaining an identity of the clearinghouse server, 
Ithe-device issues -a^CA-certificate req^i^t40-1he„clearinghouse. server using that 
obtained identity. In response to the CA certificate request, the clearinghouse 
server transmits a CA certificate to the device. The device next determines 
whether the clearinghouse is a valid and secure service provider by verifying the 

20 CA certificate. Responsive to verification of the CA certificate, the device 
generates a combination of a private key and a public key and issues to the 
clearinghouse server a request for enrollment comprising the public key. In turn, 
the clearinghouse server generates a public key certificate and transmits the public 
key certificate to the device. This enables the device to securely verify the identity 

25 of the clearinghouse server and to complete device enrollment at the clearinghouse 
server. 

These and other aspects of the present invention will be shown in 
the attached drawing set and following detailed description. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a functional block diagram of the operating environment in 
accordance with an exemplary embodiment of the present invention. 

Fig. 2 is a functional block diagram of the architecture of a 
clearinghouse server in accordance with an exemplary embodiment of the present 
35 invention. 
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Fig. 3A is a logical flow chart diagram illustrating steps for 
enrolling a source device for operation with a clearinghouse server in accordance 
with an exemplary embodiment of the present invention. 

Fig. 3B is a logical flow chart diagram illustrating steps for 
5 ^completing an enrollment request, by a source device in accordance with an 
exemplary embodiment of the present invention. 

-DETAILED -DESCRIPTION OF^HE-E^-MPtARY-EMBODIMENTS 

^}j e . present invention-provides-a-clearinghouse-solution for routing 

10 multi-media communications, including telephony calls, between a source device 
and a destination device via a distributed computer network, such as the global 
Internet. The present invention also authorizes the completion of a communication 
from a source device to a destination device and collects usage-related information 
for the completed communication. The clearinghouse server constructed in 
15 accordance with the inventive concept can identify one or more available 
destination devices available to accept a communication from an authorized source 
device based upon the source of thatcommunication. An exemplary embodiment 
— ofthe-clearinghouse-server can-operate-in-either- a "WINDOWS" or "SOLARIS" 
operating system environment in support of Web-based communications in a 

20 distributed-computer network _. 

Turning now to the drawings, in which like reference numbers 
identify like elements of exemplary embodiments of the present invention, Fig. 1 is 
a functional block diagram illustrating a representative operating environment for 
an exemplary embodiment of the present invention. A communication system 100 
25 comprises one or more originating devices (such as gateways) 110, one or more 
terminating devices (such as gateways) 120, device operators 1 1 1 and 121 for each 
of the two devices, a clearinghouse server 125, and a third party server 135, each 
coupled to an Internet Protocol (IP) network 130. Although Fig. 1 illustrates an 
operating environment including only a single originating gateway 110 and a 
30 single terminating gateway 120, those skilled in the art will appreciate that the 
operating environment of the communication system 100 can include multiple 
originating gateways and terminating gateways. For purposes of this document, 
an originating gateway will be referred to as a source device, and a terminating 
gateway will be referred to as a terminating device. The IP network 130 represents 
35 a distributing computer network and can be implemented by the global Internet, a 
wide area network (WAN), or an enterprise-wide local area network (LAN). 
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To initiate a communication supported by the communication 
system 100, a calling party 105 sends an outgoing call having a called telephone 
number to the source device 110. For this representative example, the calling party 
105 has an established a relationship with the source device 110, such as a 
5 „_jsji]^c^t^ source .device. . To be an 

authorized user of the clearinghouse services provided by the clearinghouse server 
125, the gateway operators 1 1 1 or 121 can enroll source device 110 and destination 
™^device-120 -4br^ — The enrollment 
— process-involves^the-exehange-of information between-the gateway operators 111 
10 or 121, the clearinghouse server 125, and the third party server 125. (not affiliated 
with either the operators or clearinghouse server). This enrollment process is the 
subject of the present invention. Following the enrollment process, the source 
device 110 sends an authorization request message to the clearinghouse server 125 
via the IP network 130 to request the completion of the outgoing call with an 
15 available designation device 120. The authorization request typically comprises 
the called telephone number, otherwise described as the dialed number, a call 
identifier- to-uniquely identify the outgoing-call and, for certain-applications, the 
^ephone-number-forthe-^ pa^inFauthonz^ a 

calling card number and a personal identification number (PIN). 

20 If the clearinghouse server 125 determines that the source device 

lib is an authorized user of clearinghouse services, the clearinghouse server 125 
can identify one or more destination devices for handling the outgoing call. The 
source device 110 can use the information provided by the clearinghouse server 
125 in the authorization response to contact a selected destination device 120 and 
25 to complete the incoming call via the IP network 130. In turn, the selected 
destination device 120 can communicate the outgoing call to a called party 115, 
typically via the Public Switched Telephone Network (PSTN). In this manner, the 
outgoing call is connected between the calling party 105 and the called party 115 
by a combination of a distributed computer network and the PSTN. 
30 Fig. 2 is a functional block diagram illustrating the components of a 

clearinghouse server constructed in accordance with an exemplary embodiment of 
the present invention. An exemplary clearinghouse server 125 comprises an 
operating system 205, a Web server 210, an XML parser, a clearinghouse engine 
220, and a user interface 225. The clearinghouse server 125 can be coupled to a 
35 database comprising one or more configuration files 230 to support clearinghouse 
operations. 
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The platform of the clearinghouse server 125 is provided by the 
operating system 205, which is preferably implemented by Microsoft 
Corporation's "WINDOWS 2000" or Sun Microsystem's "SOLARIS" operating 
systems. Although the "WINDOWS" and the "UNIX" platforms represent 
5 __prefeixed, platforms, __it.-will— be. appreciated that the inventive concept of a 
clearinghouse server 125 can be supported by other operating systems and is not 
limited to those described herein. The operating system 205 communicates with 

— the*Web-server2t0: 

-The-Web- server-2iO-supports-Web=based-communications with 
10 client computers in a Web-enabled computing environment, including the source 
devices illustrated in Fig. 1. The XML parser 215 can accept messages from the 
clearinghouse engine 220 and convert those messages to XML format for 
communication via the Web server 210. The XML parser 215 also can extract 
information from an XML message received by the Web server 210 and supply the 
15 extracted information to the clearinghouse engine 220. The Web server 210 also 
communicates with the user interface 225 via application programming interfaces 
- — (APIs)r~The Web server 210 is preferably implemented by an~"XITAMF' server 
"~avaiIable fromiMatix*Corporation~sprl ofAntwerpenrBelgium: * 

The clearinghouse engine 220 supports the processing of 

20 clearinghouse-transactions and communicates with the operating system 205, the 

Web server 210, and the user interface 225. APIs can be used to access functions 
supported by the clearinghouse engine 220. The clearinghouse engine 220 also can 
access configuration files maintained by the configuration database 230 in support 
of clearinghouse transactions. The configuration files typically contain descriptive 
25 information identifying characteristics of enrolled source devices and 
clearinghouse transaction records, including transaction identifiers assigned to 
transactions by the clearinghouse server 125. 

The user interface 225 provides a mechanism for a user, such as an 
assistant administrator, to input information about the clearinghouse environment, 
30 including details about enrolled source devices and destination devices. The user 
interface 225 also can present the user with information related to clearinghouse 
transaction records stored by the clearinghouse server 125. 

Secure Enrollment 

35 Referring again to Figure 1, the present invention provides a system 

and method for the secure enrollment of a device for operation with a 
clearinghouse server 125. Enrollment is the process of taking a network device 
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(such as a router, gateway, gatekeeper, etc.) and exchanging encrypted information 
with the clearinghouse server 125, so that later communications with that device 
can be secured. There are several types of devices, including originating devices 
110 and terminating devices 120. As the process of enrollment is described, all 
devices wi ll be refe rred to a s originating or_source devices J 10. This is not meant 
to limit the applicable devices to only source devices, but is meant to illustrate that 
any type of device can be used. Once this process is finished, the device 110 

— should-have-a certificate-thatis ^ (such as one year). 

— Onee~this4ength-of-time-has-passedrthe-ceitificate-will-expire-and thedevice 1 10 
must re-enroll. 

This invention works for any type of service or device 110 that 
requires secured communications. This includes devices 110 under the direct 
control of human users (like a personal computer or a IP-based telephone) and 
those that are automated and not under the direct control of human users. 

Exemplary Encryption Environment 

InTight of- the discussion of public keys and private-keys, a general 

— discussion-of~an exemplary~enciyption"environment~may~prove~beneficial for 
understanding the present invention. Encryption is the process of encoding data to 
prevent unauthorized_acAes.Sr_especially„duri is usually 

based on one or more keys, or codes, that are essential for decoding, or returning 
the data to readable form. _ An encryption key is a sequence of data that is used to 
encrypt other data and that, consequently, must be used for the data's decryption. 
Decryption is the process of restoring encrypted data to its original form. 

Public key encryption is a process that uses a pair of keys for 
encryption: a private (secret) key and a public key. The private key can encrypt 
messages and can create a unique electronic number (called a digital signature) that 
can be read by anyone possessing the corresponding public key. The private key 
can also be used to decrypt messages encrypted with the public key. The public 
key can be used for encrypting messages to be sent to the user and for decrypting 
the user's digital signature. 

A certification authority ("CA") is an organization that assigns 
digital certificates. A CA may be an external issuing company (such as VeriSign) 
or an internal company authority that has installed its own certificate server 125 
(such as a Microsoft Certificate Server) for issuing and verifying certificates. A 
CA is responsible for verifying the identity of a party and, if that identity is 
accepted, digitally signing that party's public key certificate. Other parties (that 
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possess and trust the CA's public key, can then verify the applicant's identity 
merely by verifying the CA's signature of the public key certificate. 

A CA certificate (sometimes called a digital certificate) is a user 
identity card for cyberspace. Issued by a CA, a CA certificate is an electronic 
5 — eredential-that-demonstrates that a-useror-site is trusted for the purposeof security 
and computer authentication. 

OvervievTbf Exemplary Enrollment Process 

The^'enrollment process Begins wftS "the "device generates a 

10 public/private key pair. It then establishes a secure communication channel with 
the clearinghouse enrollment server using the Secure Sockets Layer (SSL) 
protocol. The SSL exchange provides the device with a public key certificate for 
the enrollment server. That certificate is digitally signed by the third party 
certificate authority, who, therefore, vouchsafes for the enrollment server's 

15 identity. 

Once the secure communications path is established, the enrollment 
server"sends~the~device CA""clTrtific^eFo^ certificate 
authority. Certificates certifiecTby this additional C A will be used in subsequent 
communications with the clearinghouse. The additional CA may be the same CA 
—20 — as-is-authenticating-the enrollmentserverrbut it-neednotbe-so-By permitting them 
to differ, the present invention allows for different public key infrastructures for 
-enrollment -and - for -operational clearinghouse -communications (e.g. routing 
telephone calls). 

After receiving the CA certificate, the device then sends the 
25 enrollment server the previously generated public key. The enrollment server 
receives this public key and, either immediately or at a later time (e.g. after an 
administrator has verified that the customer intended to enroll the device in 
question), the enrollment server issues the device a certificate containing the 
device's public key. 

30 

Message Formats 

All messages sent to the clearinghouse enrollment server are carried 
in HTTP (version 1.1) POST messages. All replies are returned in responses to the 
35 POST. Each POST request contains a series of ASCII variable=value pairs, 
encoded as given in RFC 1738. Any response also consists of variable/value pairs. 
The following Table 1 lists the variables that can be included in a message. Note 
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that non-alphanumeric 
two hexadecimal digits 

cacert=<cert> 

certreq=<pkcslO> 

customer=<custID> 

device=<devID> 

nonce=<nbnce> 



operation==<reqrtype>~ 
10 password=<pwd> 

username=<usemame> 



characters are encoded as a and their corresponding 
( as specified in RFC 1738. ) 
Table 1 

base64-encoded authority certificate 
- base64-encoded certificate request . 

clearinghouse-assigned customer number 

clearinghouse-assigned device id 

random" value" toincrease security 

— — getcacertrrequestror retrieve 

password for clearinghouse services 

usemame for clearinghouse services 



The following example in Table 2 shows a sample CA certificate request message. 
In it, the device asks for the enrollment server's CA certificate in cleartext: 
15 Table 2 

POST HTTP/ 1.1 
Host: enroll ^. trans "nexixs" ."com 
content -typeT"text /plain 
Content - Length : 1 9 
-20 — connection:— Keep -Alive ■« - — 



operation«getcacert 



The response received from the enrollment server might look like the example 
25 shown in Table 3: 

Table 3 

HTTP/1.1 200 OK 
Server: TNS/1.0 
Connection: Keep-Alive 
30 Content -Type: text /plain 
Cont en t - Leng t h : 693 

status=0&certif icate=MIIB9DCCAV2gAwIBAgIRANs4gtN4kbWXlwvw8YsAj xMwD 
QYJKoZIhvcNAQEEBQAwFTETMBEGAlUEChMKVH JhbnNOZXh 1 c zAeFwO SOTAzMTgwMDA 
35 wMDBaFwOv^TAzMTgyMzUSNTlaMBUxEzARBgNVBAoTClRyYW^ 

oZIhvcNAQEBBQADgY0AMIGJAoGBAKuR4hI8P+g96Go7ihjfdQ+3VjA01pIqNjaSch+ 
eWWzbBG+q+aISa0sQM53elNuxMudoCFN27J7H4v0LuStDj +wSQzWj P4lBOQUXryltR 
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i+qwRaK5VhlwybHejOByURb4Qex5myhEbNWAxOimgCBIB2Exf4k5FJj OMUs795rlUp 
XAgMBAAGjRDBCMCIGAlUdEQQbMBmkFzAVMRMwEQYDVQQDEv^ 

lUdEwQIMAYBAf 8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAEgeTxN 
56ztf2bzu2Zxla/eOIWexTeEbjCQNNE2aFOLhp5bkVB6oQQkX7260ivOGx4IJdTv3Y 
5 -HYc7-BOilpU0jW-lPe/-DVk^ 

Wgx5PKyU9+pyLPgCoAC8D17wMGdh+oTSm 

Once~the~C^T certificate is retrieved, the certificate request is encrypted and 
transmitted to the enrollment server for approval. The initial request ( before it is 
10 encrypted ) looks like the representative example shown in Table 4: 

Table 4 

POST HTTP/ 1.1 
Host : enrol 1 . transnexus . com 
content -type : text/html 
15 Content -Length: 714 

Connection: Keep -Alive 



operatic^req^est&nonce=1502767911902931&username=mcmanus&password 
=01234567&device=134217728&customer=0&request=MIIBtTCCAR4CAQAwW2EL 

20 MAkGAl-UEBhMCWMxEDAOBgNVBAgTB G dlb 3 JnaWExGDAWBgNVBAoTD IRyYW 5 2 TmV4 dX 

MaIExMQ2EgMB4GAlUEAxMXdGVzdHRlcDQudHJhbnNuZXhlcy5jb20wg28wDQYJKoZI 
hvcNAQEBBQADgY0AMIGJAoGBALhYeWbF8HrVIRVMW4p2H2DZhs9tEisHelynyUEIcC 
4n9CLW104HW0zeSzNMtYBQrqJ6qZMhc0RKZ%2BMQA9ElS9hvN8TLo4KDBPXmQWE0g6 
R9f3TokpIhOJ4bOwpj 9WeXAiyNyTq7hTgQdtPYN65xq92t5CkHpWBWEya9v2Ux9I27 

25 AgMBAAGgGj AYBgkqhkiG9w0BCQcxCxMJcGFzc3dvcmQAMA0GCSqGSIb3DQEBBAUAA4 
GBAFC7sCjCbmVgUYenJR8XgMtLilQFSSq4 YJ9BcmiYsZZ6K0xFxNgEf 84wyRscdrP9 
LV9EhQM% 2BS3 gEAEw%2 FLxCRHGGgyS 1 % 2 FYpNmavs 5 1 1 hGep 1H% 2BAFW% 2 Binds 9CY 
UwyKx%2F8veFJFC6y6pYhD7RyZxyKNnzBhgxAxU3rUgr3Cm78RbTlG 

30 The retrieve function only differs in the "operation" parameter, in which the 
"request" value is replaced by "retrieve". Otherwise, all parameters have the same 
names and values. 

If the enrollment request is pending further approval, then the enrollment server is 
35 only required to send the status of the certificate request. It may send a nonce along 
with the response, but this value is not guaranteed. The response should look like 
the representative example shown in Table 5: 
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Table 5 

HTTP/1.1 200 OK 
content - type : text /plain 
content - length : 3 1 

5 

status=l&nonce=AlF0765F71C9E6AD 



If the enrollment request has"been~processed~and~accepted by the server, it will 

— return a response-such as thefollowing~in-Table-6.-Note that a status of 0 indicates 
1 0 that the certificate is now ready for retrieval. 

Table 6 

HTTP/1.1 200 OK 
content-type: text/plain 
content -length: 694 

15 

status = 0&cert=MIICf jCCAeegAwIBAgIQARAm+prL9zmocf kRWNNOf jANkqhkiG9w 
OBAQQFADAV... 



Fig. 3A is a logical flow chart diagram illustrating exemplary steps 
-20 - completed during the enrollment of a source device for operation with a 
clearinghouse server. Turning now to Fig. 3A, an exemplary enrollment process 
300 is initiated in response to a user, typically an assistant administrator, defining a 
source device to be enrolled as a "user" or subscriber of clearinghouse services. A 
source device is typically identified by an IP address or a Domain Name System 
25 (DNS) name. In addition, the administrator can assign the source device to a 
particular Group of devices having one or more common characteristics. 

In step 310, commands are issued at the source device to complete 
an enrollment request for transmission to the clearinghouse server. These 
commands are typically device dependent and often require support by an 
30 administrator to select the appropriate enrollment instructions. Representative 
enrollment request tasks completed by the source device for step 310 are shown in 
the logical flow chart diagram of Fig. 3B. 

Turning briefly to Fig. 3B, the source device obtains the identity of 
the clearinghouse server in step 330. The identity is typically an IP address or a 
35 DNS name for the clearinghouse server. In step 335, the source device obtains a 
certificate authority (CA) certificate from the clearinghouse server 335 based upon 
an initial contact with the identified clearinghouse server via the IP network. In 
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decision step 340, an inquiry is conducted to determine if the CA certificate can be 
verified as a certificate issued by a trusted device. For example, the verification 
task in decision step 340 can be completed by an administrator of the source device 
contacting a representative of the services offered by the clearinghouse server to 
5 yerifyjhe^CA certificate. . If the.CA_cjntific.ate can not Jbe verifiedjn decision step 
340, the "NO" branch is followed to step 345 and the enrollment request process is 
terminated at the source device. Based on a positive response, however, the 
-"YES" branch- is-follo wed fronrdecision step 340 to step 350. In step 350, the 
— source-device-generates-a- public/private-key pair and sends an enrollment request 
10 with the public key to the clearinghouse server 350 via the IP network. Upon 
device enrollment, a configuration record or file for that device is constructed for 
storage in the configuration database accessible by the clearinghouse server. 

Returning now to Fig. 3A, the source device sends an enrollment 
request via the IP network to the clearinghouse server in step 315. Responsive to 
15 the enrollment request, the clearinghouse server creates a public key certificate and 
sends that certificate to the source device via the IP network. This public key can 
be used by the source device to initiate secure communications with the 
clearinghouse server. In step 325, the clearinghouse server obtains device 
information and builds a configuration file for the source device. The 

. .20- configuration_fileJs_mainlained_at Jhe_configuration_database_and Js_accessible .by 

the clearinghouse server. A representative configuration file is shown in Table 7. 

Table 7 

license 'software license key 1 
25 crypto Tceys' 

enroll enabled 

routing enabled 

cdrs enabled 

ssl enabled 
30 group " 

group 'ACME ITSF 

group BT-Concert' 

group 'HK Telecom' 

group Trepaid' 
35 device 'device8.isp.com' " enabled enrolled 

device 'device 1. itsp.com' 'ACME ITSP 1 enabled enrolled 

device 'device2.itsp.com' 'ACME ITSP' enabled enrolled 

device 'device3.itsp.com' 'ACME ITSP 1 disabled enrolled 
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device t device4.carrierxom' 'BT-Concert 1 enabled enrolled 
device ! device4.com* 'HK Telecom 1 enabled 
device 'device5.com' UK Telacom 1 disabled 
device 'device6.isp.com' Prepaid' enabled enrolled 
5 device 'device7.isp.com' Prepaid' enabled enrolled 

route " '+1...' 'devicel.itsp.com' 60 'device2.itsp.com' 25 'device3 .itsp.com 1 15 

, device4.carrier.com , 0 
imite" ,, " , ^l~404~ , 'devicel~itspTcom' 75~ , device2.itspxom , ~25' t device4TcaITier.com , 0 
route t, , +~l~77G— ''device hitspxom'-TS , device2:itsp:com , -25-'device4.ca^Tie^:com , 0 
1 0 route " '+33...' 'device4.com' 1 'device5.com' 0 
route M '+33 6...' , device4.com ! 1 'device5.com' 0 
route " '+46...' 'device4.com' 1 *device5.com' 0 
route " '+46 70../ 'device4.com' 1 'device5.com' 0 
route " " 'device6.isp.com 1 100 'device7.isp.com' 0 'device8.isp.com' 0 
15 route 'ACME ITSP' '+!...' 'devicel.itsp.com' 60 'device2.itsp.com' 25 
'device3.itsp.com' 15 l device4.carrier.com' 0 
route "'ACME ITSP' '+1 404...' 'devicel. itsp.com' 75 'device2.itsp.com' 25 

'device4.carrier.com 1 0 
route 'ACME ITSP' '+1 770...' 'devicel.itsp.com' 75 'devk^.itsp.com' 25 

-20 yevice4.carrier.com-0 — 

route 'ACME ITSP '+33...' 'device4.com' 1 'deviceS.com* 0 
route 'ACME ITSP' '+33 6...' 'device4.com* 1 'deviceSxom* 0 - 
route 'ACME ITSP' *+46...' 'device4.com* 1 'deviceS.com' 0 
route 'ACME ITSP' '+46 70...' 'device4.com' 1 'device5.com' 0 
25 route 'ACME ITSP' " *device6.isp.com' 1 00 'device7.isp.com' 0 'device8.isp.com' 0 
route 'BT-Concert' '+1...' 'devicel.itsp.com' 60 'device2.itsp.com* 25 

'device3.itsp.com* 15 , device4.carrier.com' 0 
route BT-Concert' *+l 404...* 'devicel.itsp.com' 75 *device2.itsp.com' 25 
, device4.carrier.com* 0 

30 route BT-Concert' '+1 770...' 'devicel.itsp.com' 75 'device2.itsp.com' 25 
'device4.carrier.com' 0 

route BT-Concert' '+33...' 'device4.com' 1 'device5.com' 0 

route BT-Concert"+33 6...' 'device4xom' 1 'device5.com' 0 

route BT-Concert' '+46...' 'device4.com' 1 'device5.com' 0 
35 route BT-Concert' '+46 70...* 'device4.com' 1 'device5.com* 0 

route BT-Concert' M 'device6.isp.com' 100 'device7.isp.com* 0 'device8.isp.com' 0 
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route UK Telecom 1 '+1...' 'devicel.itsp.com' 60 'device2.itsp.com' 25 

'device3.itsp.com' 15 , device4.carrier.com l 0 
route UK Telecom 1 '+1 404...' 'devicel. itsp.com' 75 , device2.itsp.com' 25 

'device4.carrier.com' 0 
5 route UK. Telecom'. '+1 770...' -'devicel.itsp.com' .75 'dev^.itsp.com 1 25 

'device4.carrierxom' 0 
route 'HK Telecom' '+33...' 'device4.com' 1 'device5.com' 0 
route 'HK-Telecom'-'+SS-d;-' 'device4;com' 1 'device5.com' 0 

TOute^HKrelecom' , +46^ ,, device4TComH-'device5TCom , 0 

10 route UK Telecom' '+46 70../ 'device4.com' 1 'device5.com' 0 

route *HK Telecom' " 'device6.isp.com' 100 'device7.isp.com' 0 'device8.isp.com' 0 
route Trepaid' " 'device 1. itsp.com 1 60 'device2.itsp.com' 25 'device3.itsp.com' 15 

'device4.carrier.com' 0 

15 Each line in a configuration file (other than comments or blank 

lines) contains a single configuration item. The first word on the line identifies that 
item. The possible values for this word are listed below inTable 8. 



Table 8 

-20 license: software JicenseJcey-for-the-clearinghouse server 

crypto: cryptographic keys for the clearinghouse server 

enroll: flag to enable/disable device enrollment 

routing: flag to enable/disable call routing 
cdrs: flag to enable/disable CDR collection 

25 ssl: flag to force clearinghouse server requests to use 

SSL for security 
group: a group (convenient collection) of devices 

device: a device (gateway, gatekeeper, proxy, Softswitch, 

etc.) 

30 route: a route for a call 

The same configuration item may be included multiple times in this 
file. In such cases, the clearinghouse server's behavior depends on the specific 
item. In most cases, later occurrences of an item will override an earlier value. For 
35 example, if multiple "license" lines are included in the file, only the last line will 
actually be used by the server. In the case of "group", "device", and "route", 
multiple occurrences define additional groups, devices, or routes. Note, however, 
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that it is not possible to define multiple groups with the same name, multiple 
devices with the same name, or multiple routes with the same group and called 
number. If the configuration file attempts to define duplicates, the server will 
generate an error when attempting to read and parse the file. 

5 - .^-.^^ _ 

license "software license key" 

The content following the license keyword should be a software 
" '^icrere from 
— the fileror if ^the included licenselceyis^nvalidrthe-underlying-soflware-supporting 
10 operations of the clearinghouse server will revert to a trial version. New software 
license keys may be obtained from a licensor of the clearinghouse server software. 
They can either be added to the configuration file manually or imported into the 
server through the user interface. Imported license keys are stored in configuration 
backups. Unlike other configuration items, old values of the license key are kept in 
1 5 the configuration file, allowing a straightforward reversion to an earlier license (by 
deleting the newest license keys), as well as problem diagnosis and auditing. 

— crypto "cryptographic parameters" 

The content following the crypto keyword should be cryptographic 
20 parameters„for^the. clearinghouse server enclosed- in double quotation marks. If this 
parameter is absent, the clearinghouse server will automatically generate new 
cryptographic parameters. If this occurs, though, all enrolled devices will have to 
re-enroll with the server to refresh their cryptographic knowledge. 

25 enroll {enabled I disabled) 

The content following the enroll keyword should be a single word, 
either "enabled" or "disabled" (without the quotation marks), whichever is 
appropriate. If this parameter is not present, device enrollment will be disabled. 

30 routing (enabled I disabled) 

The content following the routing keyword should be a single word, 
either "enabled" or "disabled" (without the quotation marks), whichever is 
appropriate. If this parameter is not present, call routing will be disabled. 

35 cdrs (enabled I disabled) 

The content following the call details records) (cdrs) keyword 
should be a single word, either "enabled" or "disabled" (without the quotation 
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marks), whichever is appropriate. If this parameter is not present, CDR collection 
will be disabled. 



ssl (enabled I disabled} 

-5 — The content following-the-ssl-keyword should be-a-single word, 

either "enabled" or "disabled" (without the quotation marks), whichever is 
appropriate. 



gy.p U p- na ine 

10 The content following the group keyword should be the name of the 

group. If the name consists of more than one word, the entire name should be 
enclosed in double quotation marks. 



device name group {enabled I disabled! [enrolled] 
15 The content following the device keyword should be the DNS name 

of the device, the name of the group to which the device belongs (enclosed in 
~ ~^d®ioh~ marks "if the name is mbre~than one word), the word "enabled" or 
"disabled" (without the quotation marks), and, optionally, the word "enrolled" (also 
without quotation marks). 

20 

route group number ( device weight ) 

The content following the route keyword should be the name of the 
group to which the route applies (enclosed in quotation marks if the name is more 
than one word), the called number prefix for the routes (enclosed in quotation 
25 marks if the number includes spaces) and then a series of one or more device 
weight pairs, where device is the DNS name of the destination device, and weight 
is the weighting factor for that device. 

It should be understood that the foregoing relates only to illustrative 
30 embodiments of the present invention, and numerous changes may be made therein 
without departing from the spirit and scope of the invention as defined by the 
following claims: 
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What is claimed is: 

5 1 . A method Jb^secure-eniollment-of a^devicei-with seiyices of a 

clearinghouse enrollment server supporting communications completed by an 
Internet telephony system, comprising the steps: 

initiating a request by the device to enroll for the services of the 
clearinghouse enrollment server, 
10 verifying an identity of the clearinghouse enrollment server by using a 

security infrastructure comprising the Secure Sockets Layer (SSL) and a public key 
infrastructure; and 

responsive to verifying the identity of the clearinghouse enrollment server, 
completing enrollment of the device to access the services of the clearinghouse 
15 enrollment server. 
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2. A method for secure enrollment of a device with services of a 
clearinghouse server for an Internet telephony system, comprising the steps: 
obtaining an identity of the clearinghouse server, 

issuing a CA certificate request from the device to the clearinghouse server 



5 using the obtained identity; 

responsive to the CA certificate request, transmitting a CA certificate from 
the clearinghouse server to the device; 

determining by the device the verification of the CA certificate; 
responsive to verification of the CA certificate, generating a combination of 
10 a private key and a public key and issuing to the clearinghouse server a request 
from the device for enrollment comprising the public key; 

responsive to the device enrollment request, generating a public key 
certificate at the clearinghouse server and transmitting the public key certificate to 
the device, thereby enabling the device to securely verify the identity of the 
1 5 clearinghouse server; and 



responsive to verifying the identity of the clearinghouse server, completing 
enrollment of the device to access the services of the clearinghouse server. 
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